Size Change: -12 B (0%)

Total Size: 1.04 MB

_{compressed-size-action}

Thank you for so patiently improving the Safari experience. It will make a lot of people happy.

In this case, I do appreciate seeing a white flash rather than the very dark flash present before. However it's still a bit of a bandaid, and introduces some other issues:

• Note how in tablet and mobile previews I see some white at the bottom of long pages, the dark color now not spanning to the end.
• Note how when editing templates, there are two scrollbars, one for the content, one in the dark canvas.

I suspect to land this we'll want to compare exactly which bits scroll and how, to make sure that's 1:1 — I know that's something Jay spent a lot of time getting just right.

I noticed this while testing another PR, but in trunk with the same content, we see the background color flashing only in some themes. For example Armando vs Twenty Fourteen. Let me see if I can isolate that

Apparently changing the font-size is enough to do it?

So I tested this out at various font-sizes, and mapped where the background flash doesn't appear. The one thing I did notice is that the compositing layer for block-editor-block-list__layout increases in size as font-size changes:

To see compositing layers, click on the layers tab in safari devtools:

Nice, I created a base case outside of Gutenberg see https://gist.github.com/gwwar/4d674b0ef9618fd0a5df0e25db969b19

I'll try whittling that down further but we can see what happens when the compositing layer is too large, we'll get a pink background bleed:

This doesn't happen when the compositing layer is smaller (say we decrease the font-size):

I couldn't seem to manage to replicate this on my laptop screen.

One thing I recall from back in the day was that something like transform: translate3d(0,0,0) would trigger the GPU engine and improve rendering of complex layers by moving then onto a separate "plane" or something.

https://davidwalsh.name/translate3d

Not sure if that works as I can't replicate but worth considering?

This is wild. I'm going to dig in deeply on this and see what I can learn, if anything.

One thing I recall from back in the day was that something like transform: translate3d(0,0,0) would trigger the GPU engine and improve rendering of complex layers by moving then onto a separate "plane" or something.

Thanks for looking, yes — translate hacks also including translateZ(0) and even will-change: transform; mostly fixes the issue. We have that as a plan B fix in #32575. The reason it's a plan B is that we haven't yet been sure why the flickering happened, meaning it could potentially point to some deeper issues, perhaps even browser issues. But yeah if we don't solve it, we'll have to do that.

I'm super impressed that you managed to isolate this. But I'm afraid I can't replicate the tearing:

This is Safari 14.1.1 on an iMac. I'll try on a laptop now, but it seems regardless of font size or otherwise, I can't see it.

But let's say you've isolated it, and it's related to compositing layer size — where do we go from there? As best I can get the next step is a webkit bug report and potentially #32575 as a bandaid?

I tested on my macbook, and for the briefest moment I was able to see the flash of pink. It was only once, and it happened ever so briefly when scrolling past an image, but notably also scrolling down the page to where I hadn't been before. That last bit could be a coincidence, but mentioning in case there's some off-screen caching going on.

I tested on my macbook, and for the briefest moment I was able to see the flash of pink.

If y'all check the layers tab what we're interested in is the content div layer getting larger in area. I suspect the trigger point is going to be different for different machines and what GPU they have.

I'll see if I can try and force the compositing layer to be larger in the test case. This is also possible locally by using a monitor with a high resolution and maximizing the page.

Do memory/gpu throttling tools exist that we could leverage?

🤔 I'm not sure there are tools to simulate reduced GPU memory. I think I can come up with a test case using a bunch of large rectangles that should probably do it.

The overflow:auto is adding --webit-overflow-scroll:touch which gives us a compositing layer reason. It overall seems a bit odd to me as a safari browser default since that's likely to hit memory issues with enough content in the pane.

Ooh while refining the test case I think I uncovered something else. Ideally the compositing layer should only be the size of the scrollable pane. For example, just the visible bits we see in red:

However in Gutenberg, there are other compositing layers that intersect, which might explain how this content layer got so large. I'll try to replicate this in the test base case.

For the compositing layer size tangent I went ahead and wrote up my findings here:

#32824

I've updated the approach to move the background color to a different div that isn't a compositing layer. So this is ready for another round of reviews.

Note this fixes the background flashing only, I plan on fixing the flickering text in #32824

I took this for a spin. The "tearing" of the background seems very much fixed for me, very nice! As seen in the GIF there's still the flickering with the fixed position block toolbar, but you're aware of that (#32824).

Looks like Android E2Es are also broken in trunk from "adb: no devices/emulators found", so the red run there is unrelated to this change.

In unrelated testing today I noticed a dark scroll bar in the main canvas in Firefox, in trunk. I believe this PR might fix that as well.

I'll merge once I can get the other E2Es green. Will try rebasing with trunk

Thanks for the reviews @jasmussen @getdave !

Is this something we want to include in WP 5.8?

Is this something we want to include in WP 5.8?

@youknowriad Sure, if the the window is still open for that 👍 I think this should be relatively safe to try.

To expand on what but I think this also fixed, here's what I saw in Firefox before:

Here's after:

I've filed a bug in webkit https://bugs.webkit.org/show_bug.cgi?id=227532 and added a much smaller test case here. I think there's a combination of needing a fast repaint rate (which is easier to trigger with a mousewheel) plus a large compositing layer to slow down the speed of repaints.

https://codepen.io/gwwar/pen/BaRawoz or https://gist.github.com/gwwar/0bbe359ea9830cb959774f6ee6e94b75

It should look like this if folks manage to trigger the glitch:

If folks have trouble seeing the pink, try triggering a lot of scrolls in dev console like:

for ( i =0; i<100000; i++) { document.querySelector('.scrollable').scroll( { top: i } ); }

And then trigger a scroll from the user (via touchpad or mouse).

I also isolated the scrollbar drawing that layer instead of drawing the scrollbar control in:
https://codepen.io/gwwar/pen/VwbYgmR

It should look like this with the bug:

I'll file a WebKit bug once I get some +1s that this also triggers for other folks. Verified by others 👍

This one also requires scrollbars to be shown:

Filed this one to: https://bugs.webkit.org/show_bug.cgi?id=227545